why not standard property input-enable? Btw, this property is behaving as a boolean, so should be bool, and naming should use dashes, not underscores.

please, use: bias-pull-down. List of options seems to only list a single pull-down resistor value.

as in RT the two options is set to one set of bits, IMHO, keep the naming stupid and simple is better, rather than to fit to an enforced rules which just make the code hard to read.

This topic was largely discussed and was done for a reason: standardize as much as possible (remember Zephyr is multiplatform) and to align with other projects (Linux) that already have gone through this problem. I'm afraid we can't now make exceptions because a vendor doesn't like it. Of course, you can always take the time to make an alternative proposal if you think the current solution needs to be improved.

may input-schmitt-enable be suitable? Again, it should be a boolean

as user, when I see below two options

      input-schmitt-enable:
        required: false
        type: boolean
        description: enable schmitt-trigger mode

      input-schmitt-disable:
        required: false
        type: boolean
        description: disable schmitt-trigger mode

I am quite confused on this, and I prefer to keep this as RT user manual named so.

standard drive-strength can be used (you can customize it as ST/GD does for slew-rate)

it is already customried, and no other platfrom can reuse this rule. I would rather to have NXP dedicated naming, if it is only apply to NXP platform. but leave @danieldegrasse to decide.

standard drive-open-drain can be used

note: if you make CONFIG_PINCTRL=y default, I think DT node should also be defaulted to okay

suggestion: consider defaulting properties to SoC defaults, so that only required fields have to be defined. In many cases, only a few properties need to be adjusted (at least this is the case for ST/GD/Nordic)

Is this possible with pinctrl groups? With nodes like ST uses you can define the majority of the overrides at the SoC level, but with pinctrl groups the definition of the pinctrl node is placed within a board specific group. Default groups could be created for each SOC enabled within Zephyr, but that seems like it would deviate from the two pinctrl methods explained in Zephyr's documentation.

Of course, there's also the possibility that pinctrl nodes like ST uses are the preferred method. If that's the case, let me know and I can rebuild this PR to use that approach.

By defaults I mean defaults in the binding file. If set to SoC defaults, then properties resolve to those values if not defined. For example, assume SoC default for nxp,speed is 2, then just set that property to 2 as default so that you don't need to define it for every group unless it has to be changed to another value.

Example: https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pinctrl/gd%2Cgd32-pinctrl-af.yaml

I can set a "sane" default for in the binding file, but different pins on RT parts have different SOC level configurations at boot, so some pins would get incorrect defaults assigned.

You can also have multiple compatibles if parts differ (already happens in some other places, e.g. ST PLL nodes, you can have st,stm32f4xx-pll-clock.

Any reason this is conditionally included.

This specific ifdef is not required, although it does reduce the total include dependencies when pinctrl is disabled. The remaining ifdefs in the driver are required, but do you think this one should be removed?

Since we are transitioning to PINCTRL why should we provide an non-PINCTRL option?

Long term, we should not. Short term, we need to to allow pinctrl to be conditional because boards that do not support it will fail to build using the driver if it requires pinctrl

As long as you don't have all drivers for the given SoC converted from pinmux to pinctrl, you should keep #ifdefs in the drivers. Otherwise, end-users will end up using a hybrid pinmux/pinctrl solution, where they need to investigate the source code of each enabled driver to see if they need to it up using pinctrl dts or pinmux.c.

What is the purpose of this file?

I believe it was present for future use within the DTS, but it is not needed now. I've removed it.

Could use PINCTRL_STATE_DEFAULT for state.

Similar addition can be made to the uart yaml file

We can't make an addition like this to to the uart yaml file until all boards supporting the uart driver also support pinctrl. If we add something like this, it effectively means all in tree boards with the kinetis-lpuart peripheral need to support pinctrl

This is because without defined pinctrl nodes for an LPUART node, adding these properties will cause the build to fail. It's the same issue that we have with using the #ifdef CONFIG_PINCTRL guards in the actual driver. In the case of the i2s driver, all boards that use it must support pinctrl, so these properties are fine and the ifdef guards aren't needed.

Nitpick: missing capitalization at beginning of sentence

Will it? It naively looks to me like this is configuring the behavior if that GPIO is used as SCL, but it doesn't seem to be actually selecting that pin for this purpose. Is this line correct? Just checking.

All defaults must be justified. This has no justification. Please fix it.

https://docs.zephyrproject.org/latest/guides/dts/bindings.html#rules-for-mainline-bindings

Missing justification

Missing justification

Missing justification

Do you need this line? If it's going into the boards directory like this, I guess it will be maintained by hand from now on; it's not clear why the comment that it was generated is relevant.